The integrated circuit System-On-Chip (SOC) field has arisen as the amount of digital logic placed on a single semiconductor chip has substantially exceeded the amount of digital logic required by a single functional element. SOC technology uses the increased capacity of modern integrated circuits to create separate functional elements, or Intellectual Property (IP) blocks, on the same semiconductor chip. The separate IP blocks are connected and interconnected to satisfy the designer's system-level requirements. Each IP block can be quite complex and can do substantial amounts of work both with and without predetermined cycle by cycle interaction off the SOC. The IP blocks can also simultaneously run several different software programs, some of which may interact with other IP blocks on the SOC, as well as with devices off the SOC.
The IP blocks on a modern SOC can include multiple processing cores (e.g., microcontrollers, central processing units, etc.), multiple memories (e.g., volatile and non-volatile, cache, etc.), multiple peripherals (e.g., DMA engines, interrupt controllers, interface units, timing circuits, etc.), and the like. The modern SOC must also contain the necessary interconnects between the IP blocks within the SOC, as well as from the IP blocks to off-chip connections.
Typically, SOC IP blocks are reused from pre-designed and pre-verified IP blocks. However, an SOC designer still has to manually instantiate the reused IP blocks and manually create the interconnects between the IP blocks. This manual portion of the SOC design process is error-prone, time-inefficient, and costly.
This reuse of IP blocks has allowed for the creation of SOC platform-specific design environments. In these design environments, a portion of the SOC is pre-defined by the platform specification, thereby speeding up the SOC design process. However, such pre-defined platforms require use of a static bus structure, a particular memory, a basic real-time operation system, and a finite set of IP blocks that are specific to the platform. Each of these requirements limits the flexibility of the SOC designer to customize the SOC. Therefore, the SOC designer must sacrifice flexibility and customization for the decreased time-to-market offered by the platform-specific design environment.
Existing SOC platform design environments are either fixed for a special application with limited extensibility using predefined bus protocols or configurable from a fixed set of components that the user can mix and match. The abstraction of signal level connectivity is obtained by describing a system using predefined industry standard or proprietary interconnect/bus specifications, where components of the system can only be connected through these fixed number of interface types.
FIG. 1 illustrates a simplified example of the typical SOC design flow as is known in the art today. As shown in FIG. 1, architecture is sketched and a high level C-model is created for system simulations of functionality and performance using application snippets. If the system simulations of the architecture are unacceptable, then the C-model can be iteratively changed until the simulations are acceptable. These stages of the design are usually worked on by software engineers, perhaps with some consultation with hardware designers.
As also shown in FIG. 1, in parallel and independently, a hardware description language (HDL) model is written for the hardware, usually by hardware design engineers using a system architecture specification as their starting point. Thus, the software and hardware models are typically generated independently, and usually manually, by different engineering groups and disciplines. The HDL model is then converted to a gate level, or register transfer level (RTL), model and goes through the physical design process. If design goals are not met, architectural changes might be required. These changes are made to the HDL model and to the C-model, again, independently and manually, because there is no common source of representation of the system architecture and the changes cannot automatically be reflected from a single original source to all models. The feedback loop between the final physical design and the architecture is not a closed loop and any iterations made require many manual changes to different models and tools and is therefore extremely error-prone.
More recently, the SOC design flow allows for component reuse, with a limited ability under specific platform constraints, to write some new components. This newer generation design flow is equally as inefficient as the typical SOC design flow of FIG. 1 because, even though design of components can be reused, the system model must be manually rewritten to incorporate the components and to redesign the interconnects for each design iteration.
Therefore, what is needed is an automated SOC hardware and software cogeneration design flow that allows the SOC designer, using a single source description for any platform-independent combination of reused or new IP blocks, to produce a configured hardware description language (HDL) description of the circuitry necessary to implement the SOC, while at the same time producing the development tools (e.g., compilers, assemblers, debuggers, simulator, software support libraries, reset sequences, etc.) used to generate the SOC software, and the diagnostic environment used to verify the SOC.